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DIGITAL LIVING NETWORK ALLIANCE (DLNA) GUIDELINES 
Part 5: DLNA Device Profile guidelines 


1 Scope 

This part of DLNA Guidelines specifies guidelines that define various DLNA Device Profiles. A 
Device Profile is a collection of DLNA capabilities and features within a DLNA device. A device is 
compliant with a Device Profile, when it conforms to all the guidelines listed for that Device Profile. 

In practice, Device Profiles reference existing optional or recommended DLNA guidelines, that 
enable certain features, and make those DLNA guidelines mandatory within the context of a Device 
Profile. A Device Profile may also provide some additional guidelines that complement or modify 
existing DLNA guidelines for a feature. 

A particular type of the DLNA Device Profile is the Commercial Video Profile (CVP). A CVP Device 
Profile is an extension of the DLNA guidelines that allows content from service providers and 
multichannel video programming distributers to be distributed on the DLNA network. DLNA 
Commercial Video Profiles (CVPs) are defined as Device Profiles that consistently enable 
commercial content that enters the home network through a gateway device via an interface to a 
commercial content service provider. Since different regions of the world have different 
requirements for commercial content, multiple CVPs are defined. 

2 Normative references 

The following documents, in whole or in part, are normatively referenced in this document and are 
indispensable for its application. For dated references, only the edition cited applies. For undated 
references, the latest edition of the referenced document (including any amendments) applies. 

IEC 62481 -1:2013, Digital living network alliance (DLNA) home networked device interoperability 
guidelines - Part 1-1: Architecture and protocols 

IEC 62481-1-2:2014, Digital living network alliance (DLNA) home networked device 
interoperability guidelines - Part 1-2: XDMR 

IEC 62481 -2:2013, Digital living network alliance (DLNA) home networked device interoperability 
guidelines - Part 2: DNLA media formats 

IEC 62481 -3:2013, Digital living network alliance (DLNA) home networked device interoperability 
guidelines - Part 3: Link protection 

IEC 62481-6, Digital living network alliance (DLNA) home networked device interoperability 
guidelines - Part 6: Remote user interface - HTML5 

IEC 62481-7, Digital living network alliance (DLNA) home networked device interoperability 
guidelines - Part 7: Authentication 

IEC 62481-8, Digital living network alliance (DLNA) home networked device interoperability 
guidelines - Part 8: Diagnostics 
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IEC 62481-9, Digital living network alliance (DLNA) home networked device interoperability 
guidelines - Part 9: HTTP adaptive delivery 

IEC 62481-10, Digital living network alliance (DLNA) home networked device interoperability 
guidelines - Part 10: Low power mode 

ISO/IEC 14496-12:2008 - Information technology - Coding of audio-visual objects -- Part 12: ISO 
base media file format 

W3C HTML5 HTML5 A vocabulary and associated APIs for HTML and XHTML 

htt p://www.w3 .org/TR/html5/ 

W3C SELECTORS Cascading Style Sheets Selectors Level 3, W3C 

http://www.w3.0rg/TR/selectors/ 

W3C NAMESPACES Cascading Style Sheets Namespaces Module, W3C 

www.w3.org/TR/css3-namespace/ 


3 W3C SELECTORS-API Cascading Style Sheets Selectors API Level 1, W3C 
http://www.w 3 . 0 rg/TR/selectors-api/Terms, definitions and abbreviated terms 

For the purposes of this standard, the terms and definitions, symbols and abbreviations given in 
IEC 69481 -1, as well as the following apply. 

3.1 Terms and definitions 

3.1.1 CVP 

“Commercial Video Profiles” 

DLNA Device Profile that is intended to allow commercial content acquired through a commercial 
video provider’s gateway device to be played on the DLNA network. 

3.1.2 CVP-2 Certificate 

a certificate that is either a DTCP CVP-2 Certificate or an X.509 CVP-2 Certificate. 

3.1.3 Device Profile 

collection of DLNA capabilities and features within a DLNA device 

Note 1 to entry: A device is compliantwith a Device Prof ile, when it implements all of the guidelines listed for that Device 
Profile. 

3.1.4 (DMPDMR) 

DMP Device Class and DMR Device Class that is co-located. 

3.1.5 DTCP CVP-2 Certificate 

DTCP certificate issued by DTLA to DLNA CVP-2 certified devices (client or server). 

3.1.6 X.509 CVP-2 Certificate 

X.509 certificate issued by a Certificate Authority approved by DLNA Board of Directors (e.g. DTLA) 
to a DLNA CVP-2 certified server device in the home or to a server in the cloud that complies with 
the best Internet and DLNA practices (e.g. Authentication Server, RUI-H Transport Server). 
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3.2 Abbreviations 

3.2.1 CVP 

Commercial Video Profiles 

DLNA Device Profile that allows commercial content acquired through a commercial video 
provider’s gateway device to be played on the DLNA network 

3.2.2 EAS 

“Emergency Alert System” 

3.3 Conventions 

In IEC 62481-1:2013 and this standard, a number of terms, conditions, mechanisms, sequences, 
parameters, events, states, or similar terms are printed with the first letter of each word in 
uppercase and the rest lowercase (e.g., Device Profile). Any lowercase uses of these words have 
the normal technical English meanings. 

4 Networking architecture, device models and guideline conventions 

4.1 DLNA home networking architecture 

See Clause 4 in IEC 62481 -1:2013 for a full description of the DLNA home networking architecture. 

4.2 DLNA device model 

See Clause5 in IEC 62481 -1:201 3 for a full description of the DLNA device model. 

4.3 Document conventions and conventions 

See Clause6 in IEC 62481 -1:201 3 for a full description of the DLNA document conventions. 

5 DLNA Device Profile guidelines 

5.1 Overview 

This clause describes the format of the guidelines for DLNA Device Profiles. Applicability of a 
referenced guideline to a specific Device Class is defined both by the attribute table of the guideline 
that references it, as well as by the “applicable Device Classes" column of the Device Profile 
definition in the table at the top of each Device Profile clause. 

5.2 Defined Device Profiles 

Each Device Profile begins with a table that briefly describes it. 

This table also indicates which DLNA Device Classes the Device Profile applies to. Although a 
guideline, as defined, could apply to additional Device Classes, the defined Device Profile only 
provides for the guideline’s applicability to the Device Classes listed in conjunction with the Device 
Profile. 

The definition of a Device Profile in this table (the applicable Device Classes and the Device Profile 
name) is a normative definition of that Device Profile. The Device Casses that a guideline applies to 
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within thecontext of a Device Profile arethe intersection of the Device Classes the guideline applies 
to (from its attribute table) and the Device Classes that the Device Profile applies to (from its 
introductory table). See 7.1 in IEC 62481 -1:2013 for guideline and attribute table layout 
descriptions. 


6 CVP-NA-1 guideline requirements 

6.1 Device Profile definition 

Table 1 - CVP-NA-1 Device Profile definition 


Device Profile 

- Applicable Device 

Classes (normative list) 

Name: CVP-NA-1 

Description : This is a CVP Device Profile that was designed to define a minimal 
set of functionality needed to make certain commercial content available to 
DLNA devices in North America. This does not limit the Device Profile's 
applicability to other regions and other devices. 

DMP DMR 


6.2 Media format guidelines-NA media format profiles 

6 . 2.1 

[Guideline] A Rendering Endpoint shall conform to guidelines for the following DLNA Media 
Classes: 


• AV for the US region 

[ATTRIBUTES] 





M | A | DMP DMR 

| n/a 

| n/a 

| IEC 62481-2 | XKDRV 

1 N 


[Guideline] The additional mandatory media format profiles applicable to the DLNA HND Device 
Category for the AV Media Class are 

• MPEG_TS_NA_ISO, 

• AVC_TS_NA_ISO, 

• AVC_TS_NA_T. 

[Attributes] 


A 

DMP DMR 

n/a 

n/a 

IEC 62481-2 

NY A PR 


6.3 Client architecture and protocol guidelines 
6.3.1 Baseline client 

[Guideline] A Rendering Endpoint shall conform to all the guidelines for both the DMP and DMR 
Device Classes. 

[Attributes] 


A 

DMP DMR 

n/a 

n/a 

IEC 62481-1 

9WFQZ 





IEC 62481-2 
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[Comment] This very explicitly requires the Rendering Endpoint to support all mandatory elements 
of both DMP and DMR, including mandated media format profiles and all other mandated features 
and functionality. 

6.3.2 Client device discovery and control 

[Guideline] A Rendering Endpoint shall use the <dlna:X_DLNACAP> element in the device 
description document and include in the comma-separated list of capability ID values of all the 
Device Profiles implemented. Valid capability ID values for Device Profiles are the Device Profile 
“Name:” strings, as defined in Table 1. 

[Attributes] 


A 

DMR 

n/a 

n/a 

IEC 62481-1 

6JSXN 


[Comment] UPnP AV MediaRenderer devices use the <dlna:X_DLNACAP> element to specify to 
control points of the Device Profiles that are implemented. For example “CVP-NA-1” would be 
included for a CVP-NA-1 device. See guideline 7.3.2.35.1 (GUN WJUQC) in IEC 62481 -1:2013 for 
the formal syntax of the <dlna:X_DLNACAP> element. Sample description is given below: 

<dlna:X_DLNACAP xmlns:dlna="urn:schemas-dlna-org:device-1-0"> 

CVP-NA-1 

</dlna:X_DLNACAP> 

6.4 Trick modes 
6.4.1 

[Guideline] A Rendering Endpoint shall conform to all the guidelines for playspeed trick mode, as 
modified by Table 2. 


Table 2 - Updates to existing general HTTP 
Media Transport for streaming transfer guidelines 


Guideline updated (Replace “should” with “shall”) 

Location in 

IEC 62481-1:2013 

GUN 

MM Mandatory Media operations 

7.4.1.6.31.2 

XDI2P 

MT HTTP Fast Forward ScanMedia operation 

7.5.4.3.3.8.3 

TYB9P 

MT HTTP Streaming Slow Forward Scan Media operation 

7.5.4.3.3.9.3 

3W8KS 

MT HTTP Streaming Fast Backward Scan Media operation 

7.5.4.3.3.10.3 

ZHSFA 

MT HTTP Streaming Slow Backward Scan Media operation 

7.5.4.3.3.11.3 

2DQOQ 


[Attributes] 


A 

DMP DMR 

n/a 

n/a 

IEC 62481-1 

EEVWK 


6.4.2 

[Guideline] A Rendering Endpoint that uses DLNA Link Protection shall conform to all the 
guidelines for Playspeed trick mode, as modified by Table 3. 
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Table 3 - Updates to existing general HTTP Media Transport 
for streaming transfer guidelines with DLNA Link Protection 


Guideline updated (Replace “should” with shall”) 

Location in 

IEC 62481-3:2013 

GUN 

MT HTTP Fast Forward Scan Media operation 

7.6.4.4.2.3 

SW9IL 

MT HTTP Streaming Slow Forward Scan Media operation 

7.6.4.4.2.5 

2U6TN 

MT HTTP Streaming Fast Backward Scan Media operation 

7.6.4.4.2.7 

YFQ06 

MT HTTP Streaming Slow Backward Scan Media operation 

7.6.4.4.2.9 

FFN2S 


[Attributes] 


A 

DMR DMR 

n/a 

n/a 

IEC 62481-3 

CQZOW 


6.5 DLNA Link Protection 

[Guideline] A Rendering Endpoint shall conform to all the guidelines for DLNA Link Protection. 

[Attributes] 


A 

DMP DMR 

n/a 

n/a 

IEC 62481-3 

8J2LL 


[Comment] This very explicitly requires the rendering endpoint to support all mandatory elements 
of DLNA Link Protection. 

6.6 DLNAQOS 

[Guideline] A Rendering Endpoint shall conform to all the guidelines for DLNAQOS, as modified 
by Table 4. 


Table 4 - Updates to existing QoS requirement guidelines 


Guideline updated (Replace “should” with “shall”) 

Location in 

IEC 62481-1:2013 

GUN 

NC Devices: DLNAQOS support 

7.2.5.2.3.1 

6YK2S 


[Attributes] 


A 

DMP DMR 

n/a 

n/a 

IEC 62481-1 

MFNLP 


[Comment] This very explicitly requires the Rendering Endpoint to conform to all mandatory 
elements of DLNAQOS. Network interfaces on the device need to beconformant to all requirements 
labelled for a particular interface type in the 7.2.4, Networking and connectivity: QoS requirements 
of IEC 62481 -1:2013. This includes tolerance of tags (VLAN and DSCP) and, when tagging traffic, 
tagging both VLAN and DSCP using values as defined by the DLNA guidelines. The values used 
cannot exceed the allowed maximum classifications for any given traffic type. 

7 CVP-EU-1 guidelines 

7.1 Device profile definition 

Table 5 lists the Device Profiles defined in this standard, describes them, and identifies which 
guidelines in this standard apply to them. 
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Table 5 also notes which DLNA Device Classes the Device Profile applies to. Although a guideline, 
as defined, may apply to additional Device Classes, the defined Device Profile only provides forthe 
guideline’s applicability to the Device Classes listed in conjunction with the Device Profile. 


The definition of a Device Profile in this table (the applicable Device Classes and applicable 
guidelines and GUNS) is a normative definition of that Device Profile. The Device Classes that a 
guideline applies to within the context of a Device Profile are the intersection of the Device Classes 
the guideline applies to (from its attribute table) and the Device Classes that the Device Profile 
applies to (from Table 5). 


Table 5 Device Profiles Definition and Guideline Applicability 


Device Profile 

Applicable Device 
Classes 

[Normative List] 

Applicable 

Guidelines 

GUNs [Normative 
List] 

Name: CVP-EU-1 

DMP, DMR, DMS, 

7.2.1.1 

470S4 

Description: This is a CVP Device Profile that was 

M-DMP 

7.2.1.2 

TTLON 

designed to define a minimal set of functionality 


7.2.1.3 

L3A70 

needed to makecertain commercialcontent available 


7.2.1.4 

HONEB 

to DLNA devices in Europe. Note that this does not 


7.3.1.1 

Y3ZJE 

limit the Device Profile’s applicability to other regions 


7.3.1.2 

WG5BQ 

and other devices. 


7.3.1.3 

DBGCC 



7.3.2 

ZVF95 



7.3.3.1 

XE6PM 



7.3.3.2 

QNGHA 



7.3.3.3 

S2QZM 



7.3.4 

VL2J9 



7.3.5 

NYXZ2 



7.3.6.1 

T9Y4G 



7.3.6.2 

6C3RM 



7.3.6.3 

DBSGR 



7.4.1 

MYXQ5 



7.4.2 

69073 



7.4.3 

CE2KC 



7.4.4.1 

YH6KP 



7.4.4.2 

8C9JP 



7.4.4.3 

FDP8Q 



7.4.5 

U929D 



7.4.6.1 

UBULG 



7.4.6.2 

G6NW2 


7.2 Media Format Guidelines 

7.2.1 EU Media Format Profiles 

7.2.1.1 

[Guideline] Rendering endpoints must implement the following media format profiles : 

• AVC_MP4_BL_CIF15_AAC_520, 

• MPEG_PS_PAL, 

• MPEG_TS_SD_EU, 

• M P E G_TS_S D_E U_T, 

• MPEG_TS_SD_EU_ISO, 

. AVC_TS_EU_ISO, 

• AVC_MP4_EU. 

[Attributes] 
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M | A | DMR DMR | n/a | n/a | IEC 62481-2 | 470S4 | N 

7.2.1.2 

[Guideline] The mandatory Media Format Profile applicableto the DLNA Serving Endpoint forthe 
AV Media Class is: 

• AVC_MP4_EU 

[Attributes] 

M | A | DMS | n/a | n/a | IEC 62481-2 | TTLON | N 

7.2.1.3 

[Guideline] For any AVC_MP4_EU AVC Constrained Baseline @ Level 1.3 content binary, the 
Serving Endpoint must expose the res@dlna:objectType property in the CDS item with a value of 
“Level 1.3”. The namespace "urn:schemas-dlna-org:device-1 -0" must be specified in the <item> 
element or the <dlna:objectType> element and the namespace prefix must be "dlna" when exposing 
the res@dlna:objectType property. 

[ATTRIBUTES] 

M | A | DMS | n/a | n/a | IEC 62481-2 | L3A70 | N 

7.2.1.4 

[Guideline] The DLNA MHD Rendering Endpoint must support AVC Constrained Baseline @Level 

1.3 within AVC_MP4_EU profile parameter sets. 

[ATTRIBUTES] 

M | A | n/a | M-DMP | n/a | IEC 62481-2 | HONEB | N 

7.3 Client Architecture and Protocol Guidelines 

7.3.1 Baseline Client 

7.3.1.1 

[Guideline] A Rendering Endpoint must conform to all the guidelines for both the DMP and DMR 
Device Classes. 

[ATTRIBUTES] 


A DMP DMR 

n/a 

n/a 

IEC 62481-1 Y3ZJE 

N 




IEC 62481-2 



[Comment] Note that this very explicitly requires the Rendering Endpoint to support all mandatory 
elements of both DMP and DMR, including mandated Media Format Profiles and all other mandated 
features and functionality. 

7.3.1.2 

[Guideline] An MHD Rendering Endpoint must conform to all the guidelines for both the M-DMP 
and DMR Device Classes but only for the Media Format Profiles listed in 7.2.1.4 

[ATTRIBUTES] 
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A 

DMR 

M-DMP 

n/a 

IEC 62481-1 

WG5BQ 





IEC 62481-2 



[Comment] Note that this very explicitly requires the MHD Rendering Endpoint to support all 
mandatory elements of both M-DMP and DMR, but excludes mandated Media Format Profiles for 
DMR. Differentiation between an HND renderer and this MHD renderercan be detected based on 
the presence of M-DMP in <dlna:X_DLNADOC>. 

7.3.1.3 

[Guideline] An MHD Rendering Endpoint device description document must contain a 
<dlna:X_DLNADOC> XML element to indicate implementation of the M-DMP Device Class. The 
value of the dlna-dev-class token in this element must be “M-DMP”. This is in addition to the 
<dlna:X_DLNADOC> XML element with a value of “DMR” for the dlna-dev-class token. The syntax 
and semantics forthe <dlna:X_DLNADOC> XML element is defined in guideline 7.3.2.10.2 (8CA7M) 


of IEC 62481-1. 

[Attributes] 




M | A | DMR 

| M-DMP 

| n/a 

| IEC 62481-1 | DBGCC \ 


[Comment] This provides UPnP AV MediaRenderer control points a mechanism via DLNA 
protocols to determine that the UPnP AV MediaRenderer (DMR) is a renderer for the MHD Device 
Category verses the HND Device Category and hence has different Media Format Profile 
requirements as defined in 7.3.1.2. 

Example of a compliant implementation is as follows: 

<dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0"> 

DMR-1.50 

</dlna:X_DLNADOC> 

<dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0"> 

M-DMP-1.50 
</dlna:X_DLNADOC> 

7.3.2 Client Device Discovery and Control 

[Guideline] Rendering and Serving Endpoints must use the <dlna:X_DLNACAP> element in the 
device description document and include in the comma-separated list of Capability ID values of all 
the Device Profiles implemented. Valid Capability ID values for Device Profiles are the Device 


Profile “Name: 

” strings, as defined in Table 5. 




[Attributes] 





M | A | 

DMR, DMS | n/a 

| n/a 

| IEC 62481-1 | ZVF95 

1 N 


[Comment] UPnP AV MediaRenderer devices use the <dlna:X_DLNACAP> element to indicate to 
control points the Device Profiles they implement. For example “CVP -NA-1 ” would be included for a 
CVP-NA-1 device. See guideline 7.3.2.35.1 (WJUQC) in IEC 62481-1 forthe formal syntax of the 
<dlna:X_DLNACAP> element. Sample description is given below: 

<dlna:X_DLNACAP xmlns:dlna="urn:schemas-dIna-org:device-1 -0"> 

CVP-NA-1 

</dlna:X DLNACAP> 
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7.3.3 Trick Modes 
7.3.3.1 

[Guideline] A Rendering Endpoint must conform to all the guidelines for Playspeed trick mode, as 
modified by Table 6. 

Table 6 Updates to Existing General HTTP Media Transport for Streaming Transfer 

Guidelines 

Requirement Updated (Replace “should” with “shall”) Location in IEC 62481-1 GUN 

MM Mandatory Media Operations 


MT HTTP Fast Forward ScanMedia Operation 

7.5.4.3.3.8.3 

TYB9P 

MT HTTP Streaming Slow Forward Scan Media Operation 

7.5.4.3.3.9.3 

3W8KS 

MT HTTP Streaming Fast Backward Scan Media Operation 

7.5.4.3.3.10.3 

ZHSFA 

MT HTTP Streaming Slow Backward Scan Media Operation 

7.5.4.3.3.11.3 

2DQOQ 

[Attributes] 

M A DMP, DMR M-DMP 

n/a IEC 62481-1 XE6PM 

N 


7.3.3.2 

[Guideline] A Rendering Endpoint that uses DLNA Link Protection must conform to all the 
guidelines for Playspeed trick mode, as modified by Table 7. 


Table 7 Updates to Existing General HTTP Media Transport for Streaming Transfer 

Guidelines with DLNA Link Protection 


Requirement Updated (Replace “should” with shall”) 

Location in IEC 62481-3 

GUN 

MT HTTP Fast Forward ScanMedia Operation 

7.6.4.4.2.3 

SW9IL 

MT HTTP Streaming Slow Forward Scan Media Operation 

7.6.4.4.2.5 

2U6TN 

MT HTTP Streaming Fast Backward Scan Media Operation 

7.6.4.4.2.7 

YFQ06 

MT HTTP Streaming Slow Backward Scan Media Operation 

7.6.4.4.2.9 

FFN2S 

[Attributes] 

M A DMP, DMR M-DMP 

n/a IEC 62481-3 QNGHA 

N 


7.3.3.3 

[Guideline] For every content binary that conforms to the ISO Base Media File Format ISO/IEC 
14496-12, if a streaming HTTP Client Endpoint wants to perform a Trick Mode media operation, the 
Client must locate and parsethe moov and (if present) moot boxes located within thecontent binary 
to determine the structure of the media data within the file before issuing the required HTTP GET 
request. 

[Attributes] 


A DMP, DMR 

M-DMP 

n/a 

ISO/IEC 

S2QZM 

N 




14496-12 




[Comment] This entry clarifies that the client will use the data contained within the moov and moot 
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boxes to determine byte and/or time locations in the file when decoding operations begin. This 
requirement will apply to content in conformance with AVC_MP4_EU media format profile 

7.3.4 DLNA Link Protection 

[Guideline] A Rendering Endpoint must conform to all the guidelines for DLNA Link Protection. 

[Attributes] 


A 

DMP DMR 

M-DMP 

n/a 

IEC 62481-3 

VL2J9 


[Comment] Note that this very explicitly requires the Rendering Endpoint to support all mandatory 
elements of DLNA Link Protection. 

7.3.5 DLNAQOS 

[Guideline] A Rendering Endpoint must conform to all the guidelines for DLNAQOS, as modified 
by Table 8. 


Table 8 Updates to Existing QoS Requirements Guidelines 


Requirement Updated (Replace “should” with “shall”) 

Location in IEC 62481-1 

GUN 

NC Devices: DLNAQOS Support 

7.2.5.2.3.1 

6YK2S 


[ATTRIBUTES] 


A 

DMP, DMR 

M-DMP 

n/a 

IEC 62481-1 

NYXZ2 


[Comment] Note that this very explicitly requires the Rendering Endpoint to conform to all 
mandatory elements of DLNAQOS. Network interfaces on the device must be conformant to all 
requirements labelled for a particular interface type in the Networking and Connectivity: QoS 
Requirements section. This includes tolerance of tags (VLAN and DSCP) and, when tagging traffic, 
tagging both VLAN and DSCP using values as defined by the DLNA guidelines. The values used 
must not exceed the allowed maximum classifications for any given traffic type. 

7.3.6 DLNARUI 
7.3.6.1 

[Guideline] A UPnP AV MediaServer control point must implement RUI Pull Controller capability 
(+RUIPL+). 

[ATTRIBUTES] 


A 

DMP 

DMP 

n/a 

IEC 62481-1 

T9Y4G 


7.3.6.2 

[Guideline] An HND Rendering Endpoint must support at a minimum the Ul Profile “S DU I PROF”. 

[ATTRIBUTES] 


A 

DMP 

n/a 

n/a 

IEC 62481-1 

6C3RM 


Copyright © 2014 Digital Living Network Alliance. 

Any form of reproduction and/or distribution of these works is prohibited. 












12 


7.3.6.3 

[Guideline] An MHD Rendering Endpoint must support at a minimum the Ul Profile 

“MDUIPROF”. 

[Attributes] 

M | A | n/a | M-DMP | n/a | IEC 62481-1 | DBSGR | N 

7.4 Server Architecture and Protocol Guidelines 

7.4.1 Baseline Server 

[Guideline] A Serving Endpoint must conform to all guidelines for the DMS Device Class. 

[Attributes] 

M | A | DMS | n/a | n/a | IEC 62481-1 | MYXQ5 | N 

7.4.2 Trick Modes 

[Guideline] A Serving Endpoint must conform to all the below listed guidelines listed in Table 9 for 
Playspeed trick mode, as modified by Table 6 of this standard. 


Table 9 Updates to Existing General HTTP Media Transport for Streaming Transfer 

Guidelines 


Requirement Updated (Replace “should” with “shall”) 

Location in IEC 62481-1 

GUN 

MM Mandatory Media Operations 

7.4.1.6.32.2 

T8DBH 


[Attributes] 

M | A | DMS | n/a | n/a | IEC 62481-1 | 69073 | N 

7.4.3 DLNA Link Protection 

[Guideline] A Serving Endpoint must conform to all the guidelines for DLNA Link Protection. 

[Attributes] 

M | A | DMS | n/a | n/a | IEC 62481-3 | CE2KC | N 

[Comment] Note that this very explicitly requires the Serving Endpoint to support all mandatory 
elements of DLNA Link Protection. 

7.4.4 Support for Search Method 
7.4.4.1 

[Guideline] A Serving Endpoint must conform to all the below listed guidelines in Table 10 for 
DLNA Search Capabilities. 


Table 10 Updates to Existing DLNA Search Capabilities 


Requirement Updated (Replace “should” with shall”) 

Location in IEC 62481-1 

GUN 

Search Capabilities 

7.4.1.4.12.1 

GS6QV 
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Media Class Search 

7.4.1.4.13.1 

OGWHP 

Keyword Search 

7.4.1.4.14 

54YHU 


[Attributes] 

M | A | DMS | n/a | n/a | IEC 62481-1 | YH6KP | N 

7.4.4.2 

[Guideline] A Serving Endpoint must implement no more than 5 clauses separated by the logical 
'and' and 'or' operators in the SearchCriteria argument of the CDS:Search() action. Each clause 
must support the metadata and operators specified in the Table 20 (RDX57) in IEC 62481 -1. 

[Attributes] 

M | L | DMS | n/a | n/a | IEC 62481-1 | 8C9JP | N 

[Comment] The following examples show queries with two clauses: 

(dc:date < 2005) and (refID exists false) 

dc:artist contains “Niro” or dc:description contains “Niro” 

7.4.4.3 

[Guideline] A Serving Endpoint must advertise any additional operators (beyond those described 
in the Table 20 (RDX57) IEC 62481-1) in the list of searchable properties using action 
GetSearchCapabilities(). 

[Attributes] 

M | A | DMS | n/a | n/a | IEC 62481-1 | FDP8Q | N 

7.4.5 Support for Additional Metadata 

[Guideline] A Serving Endpoint must conform to all the guidelines for DLNA Recommended 
Metadata as described in Table 11 below. 


Table 11 Updates to Existing DLNA Metadata Capabilities 


Requirement Updated (Replace “should” with shall”) 

Location in IEC 62481-1 

GUN 

Recommended Metadata, MM DIDL-Lite Recommended 
Metadata Properties 

7.4.1.3.12.3 

FB4S5 

Image & Video Thumbnail, MM DIDL-Lite Multiple Res: 

7.4.1.7.6.1 

UPXML 

Thumbnails 

7.4.1.7.6.2 

RZQRD 

Album Art, MM DIDL-Lite Audioitem Album Art 

7.4.1.4.7.1 

ZVDY7 


7.4.1.4.7.2 

YXRZ4 


[ATTRIBUTES] 


M | A | DMS | n/a | n/a | IEC 62481-1 | U929D | N 

7.4.6 DLNARUI 
7.4.6.1 

[Guideline] A Serving Endpoint must implement RUI Source Capability (+RUISRC+). 

Copyright © 2014 Digital Living Network Alliance. 

Any form of reproduction and/or distribution of these works is prohibited. 

























14 


[Attributes] 


1 A 

DMS 

n /a 

n/a 

IEC 62481-1 

UBULG 


[Guideline] A Serving Endpoint must supportthe following Ul profiles: HD_UIPROF, SD_UIPROF 
and MDJJIPROF. 

[ATTRIBUTES] 


1 A 

DMS 

n/a 

n/a 

IEC 62481-1 

G6NW2 | 


8 CVP-2 guidelines 

8.1 Device profile definition 

Table 12 — CVP-2 device profile definition 


Device Profile 

Applicable Device Classes 
and Capabilities 

Name: CVP-2_Client 

Description: This is a CVP-2 Client Device Profile that defines a full set of 
functionality required for a rendering endpoint device to access commercial 
content available to DLNA devices in North America and Europe. Th is does 
not limit the Device Profile's applicability to other regions and other devices. 

. (DMP DMR) or XDMR 
+ RUIHPL+ 

+ DIAGE+ 

+ LPC+ 

Name: CVP-2_Server 

Description : This is a CVP-2 Server Device Profile that defines a full set of 
functionality required for a serving endpoint device to make commercial 
content available to DLNA devices in North America and Europe. This does 
not limit the Device Profile's applicability to other regions and other devices. 

. DMS 

+ RUIHSRC+ 

+ DIAGC+, +DIAGE+ 

+ LPE+ 


8.2 Media format guidelines 


8.2.1 Media format profiles 

8.2.1.1 

[Guideline] A CVP-2 Client shall conform to all the guidelines for the media format profiles 
specified in Table 13 forthe regions supported by the device. A CVP-2 Client shall also conform to 
the guidelines for the required media format profiles for the rendering endpoints of HND Device 
Category for the regions supported by the device as defined in IEC 62481 -2. 


Table 13 — Mandatory media formats for North America and Europe 



North America 

Europe 

Mandatory 

Media 

Formats 

• MPEG TS NA ISO 

A VC TS NA ISO 

A VC TS NA T 

MPEG TS HD NA T 

• A VC MP4 BL CIF15 AAC 520 

A VC TS EU ISO 

A VC MP4 EU 


[Attributes] 


A 

(DMP DMR) XDMR 

n/a 

n/a 

IEC 62481-2 

S3ETP 


+ RUIHPL+ 






[Comment] This guideline mandates the region specific media format profiles for a CVP -2 Client. 
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A CVP-2 Client indicates support for regions through registration during certification. The 
mandatory media format profiles for registered regions, as defined in IEC 62481-2, for individual 
Device Class or Device Capability of the CVP-2 Client Device Profile are accounted for by this 
guideline. 

8.2.1.2 

[Guideline] A CVP-2 Client that indicates support for 3-D media shall conform to the guidelines 
associated with the following 3-D media format profiles: MPEG_TS_3DFC_ISO, 
AVC_TS_3DFC_ISO and AVC_TS_HD_3D_AC3_ISO, as defined in IEC 62481-2. 

[Attributes] 


A 

(DMP DMR) XDMR 

n/a 

n/a 

IEC 62481-2 

C3ACY 


+ RUIHPL+ 






[Comment] A CVP-2 Client indicates support for 3-D media through registration during 
certification. 

8.2.1.3 

[Guideline] A CVP-2 Server shall conform to all the guidelines for at least one of the HND Device 
Category mandatory media format profiles as specified in IEC 62481 -2 for each supported region. 

[Attributes] 


A 

DMS 

n/a 

n/a 

IEC 62481-1 

IWRSH 


+ RUIHSRC+ 






[Comment] A CVP-2 Server indicates support for its supported region(s) through registration 
during certification. 

8 . 2 . 1.4 

[Guideline] A CVP-2 Server that indicates support for 3-D media shall conform to all the 
guidelines for at least one of the following 3-D media format profiles: MPEG_TS_3DFC_ISO, 
AVC_TS_3DFC_ISO, and AVC_TS_HD_3D_AC3_ISO, as defined in IEC 62481-2. 

[ATTRIBUTES] 


A 

DMS +RUIHSRC+ 

n/a 

n/a 

IEC 62481-2 

OTL9F 


[Comment] A CVP-2 Server indicates support for 3-D media through registration during 
certification. 

8.3 Architecture and protocol guidelines 

8.3.1 Baseline client 

8.3.1.1 

[Guideline] A CVP-2 Client shall conform to allthe guidelines forthe (DMP DMR) Device Classes 
orXDMR Device Class. 

[Attributes] 
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M 

A 

(DMP DMR) XDMR 

n/a 

n/a 

IEC 62481-1 

UC6AZ 

N 






IEC 62481-1-2 




[Comment] This is the baselineclient device guidelinecommonto CVP-NA-1 and CVP-EU-1 (DMP 
DMR) Device Classes. 

8.3.1.2 

[Guideline] A CVP-2 Client shall conform to all the guidelines for the +RUIHPL+ Device Capability 


as defined in IEC 62481 -6. 

[Attributes] 




M | A | +RUIHPL+ 

| n/a 

| n/a 

| IEC 62481-6 | HRGXR j 


8.3.1.3 

[Guideline] A CVP-2 Client shall implement the GENURL Device Function as defined in 
IEC 62481-1. 

[ATTRIBUTES] 


A 

(DMP DMR) 

n/a 

n/a 

IEC 62481-1 

EFPNC 


+ RUIHPL+ 






[Comment] The GENURL Device Function is already mandated for XDMR. 

8.3.1.4 

[Guideline] A CVP-2 Client shall support all the guidelines for Playspeed scan operations (a.k.a 
trick modes), as modified by Table 14. 

Table 14 — Updates to existing general HTTP media transport for streaming transfer 

guidelines 


Requirement Updated (Replace “should” with “shall”) 

Location in IEC 62481-1 

GUN 

MT HTTP Streaming Fast Forward Scan Media Operation 

7.5.4.3.3.8.3 

TYB9P 

MT HTTP Streaming Slow Forward Scan Media Operation 

7.5.4.3.3.9.3 

3W8KS 

MT HTTP Streaming Fast Backward Scan Media Operation 

7.5.4.3.3.10.3 

ZHSFA 

MT HTTP Streaming Slow Backward Scan Media Operation 

7.5.4.3.3.11.3 

2DQOQ 


[Attributes] 


M 

R 

(DMP DMR) XDMR 

n/a 

n/a 

IEC 62481-1 

3LQVT 

N 



+ RUIHPL+ 







[Comment] This guideline mandates Playspeed trick modes on the CVP-2 Client. 

8.3.1.5 

[Guideline] A CVP-2 Client shall support DLNA Link Protection and conform to all the guidelines 
for Link Protection. IEC 62481 -3 

[Attributes] 
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M 

R 

(DMP DMR) XDMR 

n/a 

n/a 

IEC 62481-3 

BGTUT 

N 



+ RUIHPL+ 







[Comment] This guideline explicitly requires the CVP-2 Client to support DLNA Link Protection. 

8.3.1.6 

[Guideline] A CVP-2 Client that uses DLNA Link Protection shall support all the guidelines for 
Playspeed scan operations, as modified by Table 15. 

Table 15 — Updates to existing general HTTP media transport for streaming transfer 

guidelines with DLNA Link Protection 


Requirement Updated (Replace “should” with shall”) 

Location in IEC 62481-3 

GUN 

MT HTTP Streaming Fast Forward Scan Media Operation 

7.6.4.4.2.3 

SW9IL 

MT HTTP Streaming Slow Forward Scan Media Operation 

7.6.4.4.2.5 

2U6TN 

MT HTTP Streaming Fast Backward Scan Media Operation 

7.6.4.4.2.7 

YFQ06 

MT HTTP Streaming Slow Backward Scan Media Operation 

7.6.4.4.2.9 

FFN2S 


[Attributes] 


M 

R 

(DMP DMR) XDMR 

n/a 

n/a 

IEC 62481-1 

RTCIY 

N 



+ RUIHPL+ 



IEC 62481-3 




8.3.1.7 

[Guideline] A CVP-2 Client shall conform to all the guidelines for DLNAQOS, as modified by Table 
16. 


Table 16 — Updates to existing QoS guidelines 


Requirement Updated (Replace “should” with “shall”) 

Location in IEC 62481-1 

GUN 

NC Devices: DLNAQOS Support 

7.2.5.2.3.1 

6YK2S 


[Attributes] 


R 

(DMP DMR) XDMR 

n/a 

n/a 

IEC 62481-1 

2C8TL 


[Comment] This guideline explicitly requires the CVP-2 Client to conform to all mandatory 
elements of DLNAQOS. Network interfaces on the device needs to be conformant to all 
requirements labelled for a particular interface type in the 7.2.4 Networking and Connectivity: QoS 
requirements of IEC 62481 -1. This includes tolerance of tags (VLAN and DSCP) and, when tagging 
traffic, tagging both VLAN and DSCP using values as defined by the DLNA guidelines. The values 
used cannot exceed the allowed maximum classifications for any given traffic type. 

8.3.1.8 

[Guideline] The RUI-H Pull Controller Device Capability of a CVP-2 Client shall conform to all the 
guidelines for the Client Authentication Device Option as defined in IEC 62481 -7. 

[ATTRIBUTES] 


A 

+ RUIHPL+ 

n/a 

n/a 

IEC 62481-7 

N07RQ 
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8.3.1.9 

[Guideline] A CVP-2 Client shall conform to all the guidelines for the +DIAGE+ Device Capability 
as defined in IEC 62481-8. 

[Attributes] 

M | A | (DMP DMR) XDMR | n/a | n/a | IEC 62481-8 | DPLC5 | N 

8.3.1.10 

[Guideline] A CVP-2 Client shall conform to all the guidelines for the + LPC+ Device Capability as 
defined in IEC 62481-10. 

[Attributes] 

M | A | (DMP DMR) XDMR | n/a | n/a | IEC 62481-10 | XOLUC | N 

8.3.1.11 

[Guideline] A (DMP DMR) or XDMR Device Class and the +RUIHPL+ Device Capability of a 
CVP-2 Client shall conform to all the corresponding guidelines identified in the DLNA HTTP 
Adaptive Delivery Device Option for Rendering Endpoint as defined in IEC 62481 -9. 

[Attributes] 


A (DMP DMR) XDMR 

n/a 

n/a 

IEC 62481-9 BMXCH 

N 

+ RUIHPL+ 






8.3.2 Baseline server 

8.3.2.1 

[Guideline] A CVP-2 Server shall conform to all the guidelines for DMS as defined in 
IEC 62481-1. 

[Attributes] 

M | A | DMS | n/a | n/a | IEC 62481-1 | SYZI2 | N 

8.3.2.2 

[Guideline] A CVP-2 Server shall support the PlaySpeed.dlna.org HTTP header and conform to 
the guidelines for Playspeed scan operations as defined in Guideline 7.5.4.3.3.16 (MT HTTP 
PlaySpeed.dlna.org header) in IEC 62481 -1. 

[Attributes] 


M R DMS 

n/a 

n/a 

IEC 62481-1 

Y5SDT 

N 

+ RUIHSRC+ 







[Comment] This guideline explicitly requires the CVP-2 Server to support the PlaySpeed.dlna.org 
HTTP header. 
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8.3.2.3 

[Guideline] A CVP-2 Server shall support DLNA Link Protection and conform to all the guidelines 
for Link Protection as defined in IEC 62481-3. 

[Attributes] 


A 

DMS 

n/a 

n/a 

IEC 62481-3 

I5NV3 


+ RUIHSRC+ 






[Comment] This explicitly requires the CVP-2 Server to support DLNA Link Protection. 

8.3.2.4 

[Guideline] A CVP-2 Server shall conform to the guidelines for +RUIHSRC+ as defined in 
IEC 62481-6 

[ATTRIBUTES] 


A 

+ RUIHSRC+ 

n/a 

n/a 

IEC 62481-6 

83POS 


8.3.2.5 

[Guideline] The RUI-H Source Device Capability of a CVP-2 Server shall conform to all the 
guidelines for the Server Authentication Device Option as defined in IEC 62481 -7. 

[Attributes] 


A 

+ RUIHSRC+ 

n/a 

n/a 

IEC 62481-7 

RSBRU 


8.3.2.6 

[Guideline] A CVP-2 Server shall conform to all the guidelines for the +DIAGE+ Device Capability 
as defined in IEC 62481-8. 


[Attributes] 


A 

+ DIAGE+ 

n/a 

n/a 

IEC 62481-8 

2JMJP 


8.3.2.7 

[Guideline] A CVP-2 Server shall conform to all the guidelines for the +LPE+ Device Capability as 
defined in IEC 62481-10. 


[Attributes] 


A 

+ LPE+ 

n/a 

n/a 

IEC 62481-10 

NYX8F 


8.3.2.8 

[Guideline] If a CVP-2 Server supports HTTP Adaptive Delivery, then it shall conform to all the 
guidelines as defined in IEC 62481 -9. 

[ATTRIBUTES] 
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A 

DMS 

n/a 

n/a 

IEC 62481-9 

3KNJQ 


+ RUIHSRC+ 






[Comment] This guideline applies the same HTTP Adaptive guidelines to both DMS and the 
+ RUIHSRC+ Device Capability. A CVP-2 Server indicates support for HTTP Adaptive Delivery 
through registration during certification. 

8.3.3 Device discovery and control 

8.3.3.1 

[Guideline] A CVP-2 Client shall use the <dlna:X_DLNACAP> element in the device description 
document and include in the comma-separated list of Capability ID values all the Device Profiles 
implemented. The valid Capability ID value for Device Profile is the Device Profile “Name:”string for 
a CVP-2 Client as defined in Table 12. 

[ATTRIBUTES] 


A 

DMR XDMR 

n/a 

n/a 

IEC 62481-1 

QQOS9 


[Comment] UPnP AV MediaRenderer devices use the <dlna:X_DLNACAP> element to indicate to 
control points the Device Profiles they implement. For example “CVP-2_Client” would be included 
for a CVP-2 Client device. See guideline 7.3.2.35.1 (GUN WJUQC) in IEC 62481-1 for the formal 
syntax of the <dlna:X_DLNACAP> element. Sam pie description is given below: 

<dlna:X_DLNACAP xmlns:dlna="urn:schemas-dlna-org:device-1-0"> 

CVP-NA-1, CVP-2_Client 
</dlna:X_DLNACAP> 

8.3.3.2 

[Guideline] A CVP-2 Server shall use the <dlna:X_DLNACAP> element in the device description 
document and include in the comma-separated list of Capability ID values all the Device Profiles 
implemented. The valid Capability ID value for Device Profile is the Device Profile “Name:”string for 
a CVP-2 Server as defined in Table 12. 

[ATTRIBUTES] 


A 

DMS 

n/a 

n/a 

IEC 62481-1 

OYLCY 


+ RUIHSRC+ 






[Comment] An UPnP AV MediaRenderer devices usethe <dlna:X_DLNACAP> element to indicate 
to control points the Device Profiles they implement. For example “CVP -2_Server” would be 
included for a CVP-2 Server device. See guideline 7.3.2.35.1 (GUN WJUQC) in IEC 62481 -1 for the 
formal syntax of the <dlna:X_DLNACAP> element. Sam pie description is given below: 

<dlna:X_DLNACAP xmlns:dlna="urn:schemas-dlna-org:device-1-0"> 

CVP-EU-1, CVP-2_Server 
</dlna:X_DLNACAP> 

8.3.4 HTML5 remote Ul 
8.3.4.1 

[Guideline] RUI-H User Agent of a CVP-2client shall implement the [FULLSCREEN] reference as 
defined in W3C HTML5. 
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[Attributes] 

M | A | +RUIHPL+ | n/a | n/a | W3C HTML5 | 36HRD | N 

8.3.4.2 

[Guideline] The RUI-H Pull Controller Device Capability of a CVP-2 Client shall conform to the 
normative text in the following CSS Level 3 modules: Selectors Level 3 W3C SELECTORS, CSS 
Namespaces W3C NAMESPACES, and Selectors API Level 1 W3C SELECTORS-API. 

[Attributes] 

M A +RUIHPL+ n/a n/a W3C PH6PZ N 

SELECTORS 

W3C 

NAMESPACES 

W3C 

SELECTORS-API 

8.3.4.3 

[Guideline] When a CVP-2 Client displays information about a RUI-H Ul listing from a 

RemoteUIServer Service, it shall implement the following rules: 

- If the Ul listing has an <iconList> element, display one icon from the list, 

- Else if the RemoteUIServerDevice device description has an <iconList> element, display 
one icon from the list. 

- Else no icon is displayed for the Ul Listing 

[Attributes] 

M | A | +RUIHPL+ | n/a | n/a | IEC 62481-6 | UTAQT | N 

8.3.4.4 

[Guideline] When a CVP-2 Client displays information about a RUI-H Ul listing from a 

RemoteUIServer Service, it shall implement the following rules: 

- If the UI listing has a <description> element display the description, 

- Else display the <friendlyName> element from the RemoteUIServerDevice device 
description. 

[Attributes] 

M | A | +RUIHPL+ | n/a | n/a | IEC 62481-6 | 72VN9 | N 

8.3.4.5 

[Guideline] The GetCompatibleUls action from a RemoteUIServer Service of a CVP-2 Server 
shall provide at least one URL that establishes an HTTPS connection to the RUI-H Transport 
Server. 

[Attributes] 

M I A I +RUIHSRC+ I n/a I n/a I IEC 62481-6 I 9XDT6 I N 
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[Comment] This simplifies the client architecture by establishing a chain of trust with the RUI-H 
content servers at launch. 

8.3.4.6 

[Guideline] The RUI-H Source of a CVP-2 Server shall use its CVP-2 Certificate for establishment 
of all HTTPS connections with the+ RUIHPL+ Device Capability of a CVP-2 Client. 

[Attributes] 

M | A | +RUIHSRC+ | n/a | n/a | n/a | LVPBB | N 

8.3.5 Authentication 

8.3.5.1 

[Guideline] The RUI-H Pull Controller Device Capability of a CVP-2 Client shall implement DTCP 
Method using a DTCP CVP-2 Certificate for Client Authentication as defined in I EC 62481 -7. 

[Attributes] 

M | A | +RUIHPL+ | n/a | n/a | IEC 62481-7 | TML20 | N 

8.3.5.2 

[Guideline] The RUI-H Source Device Capability of a CVP-2 Server shall use a CVP-2 Certificate 
for server authentication as defined in IEC 62481-7. 

[Attributes] 

M | A | +RUIHSRC+ | n/a | n/a | IEC 62481-7 | 425MN | N 

8.3.5.3 

[Guideline] If the RUI-H Pull Controller Device Capability of a CVP-2 Client supports Server 
Authentication, it shall implement X.509 Method for Server Authentication as defined in 
IEC 62481-7. 

[Attributes] 

M | A | +RUIHPL+ | n/a | n/a | IEC 62481-7 | SEFTW | N 

[Comment] A CVP-2 Client indicates support for Server Authentication through registration during 
certification. 

8.3.5.4 

[Guideline] If the RUI-H Pull Controller Device Capability of a CVP-2 Client supports Server 
Authentication, it shall implement DTCP Method for Server Authentication as defined in 
IEC 62481-7. 

[ATTRIBUTES] 

M I A I +RUIHPL+ I n/a I n/a I IEC 62481-7 I ZEZZX I N 
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[Comment] A CVP-2 Client indicates support for Server Authentication through registration during 
certification. 

8.3.6 3-D media rendering 

8.3.6.1 

[Guideline] If a CVP-2 Client supports rendering of DLNA 3D media formats, it shall conform to all 
the guidelines for 3-D media rendering as defined in I EC 62481 -1. 

[ATTRIBUTES] 


A 

(DMP DMR) XDMR 

n/a 

n/a 

IEC 62481-1 

L5M4W 


+ RUIHPL+ 






8.3.6.2 

[Guideline] The RUI-H Pull Controller Device Capability of a CVP-2 Client shall not wait for 
confirmation from the user before switching from 3D media to 2D media. 

[Attributes] 


A 

+ RUIHPL+ 

n/a 

n/a 

IEC 62481-1 

WYLUI 


[Comment] This ensures, for example, that a RUI-H application selection of EAS is not pre-empted 
by the RUI-H User Agent. 
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Annex ACVP-2 architecture, system usages and deployment scenarios 

(Informative) 


A.1 CVP-2 device architecture 



^Mandatory component 


J Optional component J 


Figure A.1 — CVP-2 device architecture 
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A.2 System usages 

This section lists DLNA system usages supported by CVP-2. 

A.2.1 AV system usages 

CVP-2 supports following AV system usages defined in IEC 62481 -1. 

• 2 Box Model 

• 3 Box Model 

These AV system usages include the support for HTTP Adaptive Delivery IEC 62481-9 and 3-D 
media format. 

A.2.2 RUI with AV system usage 

CVP-2 supports 

• 2 Box RUI with AV System Usage 

as defined in IEC 62481-6. The usage includes the support for HTTP Adaptive Delivery and 3-D 
media format. 

A.2.3 Other system usages 

Other system usages supported by CVP-2 include 

• Diagnostics system usages IEC 62481-8 

• Low-Power system usages IEC 62481-10 


Copyright © 2014 Digital Living Network Alliance. 
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A.3 CVP-2 in-home only deployment scenario 


Note: Diagnostics and Low-Power 
(both in-home scenarios) can be 
layered on top of this diagram 


CD 


Device and Service 
Discovery 


I Authentication I 
^Device OptionJ 

c ^ 



CVP-2 Client 


Figure A.2 — CVP-2 in-home only system scenario 
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A.4 CVP-2 in-home + cloud deployment scenario 



Figure A.3 — CVP-2 in-home + cloud system scenario 
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Annex B CVP-2 authentication examples 

(informative) 

B.1 CVP-2 usage scenario without in-home CVP-2Server Authentication 



Figure B.1 


CVP-2 usage scenario (no in-home CVP-2 Server Authentication) 
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B.2 TLS-SDexchange for CVP-2 usage scenario without in-home CVP-2Server 
Authentication 


TLS-SD DH for authentication of client using DTCP Credential and server using trusted X.509 Cert 



Client messages: 

CC - Client sends an empty message if 
the server requests it 

Standard TLS messages 
Cert - Certificate 
SKE - ServerKeyExchange 
CR - CertificateRequest 
SHD - ServerHelloDone 
CKE - ClientKeyExchange 
CV - CertificateVerify 
CCS - ChangeCipherSpec 
Fin - Finished message 

Extended TLS messages 

SD - SupplementalData 

Notes: 

a. Sequence Diagram assumes server is 
using a trusted X.509 certificate (typical for 
cloud/intranet servers) & client is using 
DTCP credential with CVP-2 bit set 

b. The TLS layer verifies the X.509 cert 
before passing the SD message to the app 
layer 


Figure B.2 — TLS-SD exchange 


(no in-home CVP-2 Server Authentication) 


Any form of 


Copyright © 2014 Digital Living Network Alliance, 
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B.3 CVP-2 usage scenario with in-home CVP-2 Server Authentication 



Figure B.3 — CVP-2 usage scenario (in-home CVP-2 Server Authentication) 
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B.4 TLS-SDexchange for CVP-2 usage scenario with in-home CVP-2 Server 
Authentication 


TLS-SD DH for authentication of client using DTCP CVP-2 Credential and server using DTCP CVP-2 Credentials + self- 
signed X.509 Cert 


CVP-2 Client 


TLS App layer 


Verify 
S-DTCP Cert 
Generate 
SD 

payload 


Verify 

S-DTCP Cert 
Generate 
SD 

payload 


_SD payload + _ 

X.509 Cert 

Provide SD 
payload 

1 (Noncel+ • 
DTCP Cert + 
DTCP Sig) 


Verify X.509 
Cert (b) 


_SD payload + _ 

X.509 Cert 
Provide SD 
payload 

■ (Nonce2 + • -> 
DTCP Cert + 
DTCP Sig) 


Verify X.509 
Cert (b) 


In-home Auth Server 


TLSStvr | [ TLS Appjaver 


■ 1) TLS extended Hello messages H 

I 

2) SupplementalData message 
includes (Noncel + S-DTCP Cert + ■ 
X.509 Cert + S-DTCP Sig) 

_ 3) TLS messages 

Cert, SKE. CR. SHD 


4) SupplementalData message 
includes (Noncel + DTCP Cert - -> 
+ DTCP Sig) 

_ 5) TLS messages _ 

CC, CKE, CV. CCS, Fin 


- New Session —P 

Provide SD payload 
(Noncel + 

<- - S-DTCP Cert + 
X.509 Cert + 
S-DTCP Sig) 


-SD payload 


■ Initial TLS tunnel established - 


- 6) Hello Request - 


7) TLS extended Hello messages —I 
0) SupplementalData message 
includes (Nonce2 * S-DTCP Cert + ■ 
X.509 Cert + S-DTCP Sig) 

_ 9) TLS messages 

Cert, SKE. CR. SHD 


10) SupplementalData message 
includes (Nonce2 + DTCP Cert - -> 
+ DTCP Sig) 


I U 


— Renegotiate- 

Provide SD payload 
(Nonce2 + 
S-DTCP Cert + 
X.509 Cert + 
S-DTCP Sig) 


“SD payload ' 


■ DTCP authenticated TLS tunnel established " 


Generate 

SD 

payload 


Verify 
DTCP Cert 
Check if new 
session 


Generate 

SD 

payload 


Verify 
DTCP Cert 


tJ 


Client messages: 

CC - Client sends an empty message if 
the server requests it 

Standard TLS messages 
Cert - Certificate 
SKE - ServerKeyExchange 
CR - CertificateRequest 
SHD - ServerHelloDone 
CKE - ClientKeyExchange 
CV - CertificateVerify 
CCS - ChangeCipherSpec 
Fin - Finished message 

Extended TLS messages 

SD - SupplementalData 

S-DTCP Cert = Server's DTCP CVP2 
Certificate 

S-DTCP Sig = Signature generated using 
server's DTCP CVP2 Certificate 

Notes: 

a. Sequence Diagram assumes server is 
using a DTCP credential with CVP-2 bit set 
along with a self-signed X.509 certificate 
(typical for in-home servers) & client is using 
DTCP credential with CVP-2 bit set 

b. The TLS layer verifies the X.509 cert 
before passing the SD message to the app 
layer. If the TLS layer cannot verify the X.509 
cert, it will pass the X.509 cert along with SD 
to the app layer and let the app layer verify 


Figure B.4 — TLS-SD exchange (in-home CVP-2 Server Authentication) 


Copyright © 2014 Digital Living 
Any form of reproduction and/or distribution 


Network Alliance, 
of these works is 


prohibited. 


























































































